Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes for issues 68, 164, 167, 546, and 550 #581

Open
wants to merge 131 commits into
base: 2.7
Choose a base branch
from

Conversation

robEllenberg
Copy link
Collaborator

@robEllenberg robEllenberg commented May 2, 2019

This branch combines a bunch of old work, and some recent fixes from other branches to address some outstanding TP issues in 2.7

Fix #68 (reduce large blend arcs in G33 and prevent blends between synced and non-synced modes)
Fix #164 (smoother error correction and better velocity estimation in position sync)
Fix #167 (warns users if axis feeds are not fast enough for a G33 move at the current spindle speed)
Fix #546 (Fix some edge cases in TP including a regression in parabolic blend fallback)
Fix #550 (Fix mismatch between canon and TP's idea of what a zero-length move is, since they each have to arrive at that conclusion independently)

Note: all runtests and TP unit tests pass in a Ubuntu 18.04 x64 uspace build

…culation.

The 2.x target velocity calculation in position-sync mode causes jitter
around the target position. This commit replaces the error calculation
with a simpler version that better tracks spindle velocity.

Other changes:
* Rename and refactor to be clearer about scope and purpose
* Create a separate header for missing math functions from C math (signum and integer min / max).
* Rename the signed spindle position helper function to something more meaningful

Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
The original "error velocity" formula was correct if the initial and
final velocity was zero. However, during spindle position tracking, the
target velocity is non-zero (or it wouldn't be tracking!). This lead to
a slight over-correction, and steady-state jitter even with a perfect encoder signal.

The new formula accounts for the ideal target velocity, and should
therefore over-correct less. This fixes the jitter (in simulation with a
perfect encoder, at least).

Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
…ating encoders)

Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
Since Canon knows the spindle speed for a given segment, it's trival to
calculate the nominal feed for a synchronized motion segment (assuming
ideal spindle behavior). This nominal velocity is passed to motion so
that blend arcs can be sized correctly.

Also, report a canon error if the planner can't meet the required feed
for spindle synchronization.

Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
Fixes issue LinuxCNC#68 by preventing any blending between position-synced
motions (G33) and other motion modes (velocity-sync and normal),
according to this table.

Mode Transitions    | blending allowed
--------------------+-----------------
normal -> position  | no
position -> normal  | yes
all others          | yes

These now cases match 2.6.x behavior, though the blending itself can be
done with tangent / arc blends.

Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
We know that feed override can't exceed 1.0 during position-sync moves,
so it's a waste to plan blend arcs that allow for higher feed overrides.
This makes blend arcs a bit smaller in position-synced moves.

Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
Previously, the user could command an arbitrarily large spindle speed
with G33 / G95 motion, even if the machine axes couldn't keep up. The
user has no way of knowing that this is happening (except in extreme
cases).

This fix does two things:

1) Pop a warning message to the user telling them the maximum spindle
speed possible for the current motion.
2) Attempt to limit the spindle speed by issuing a new speed command in
the background before the synced motion starts.

Note that (2) will have no effect if the machine does not have active
spindle speed control.

Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
Reduce spam in TP debug logs.

Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
Parabolic blends require reduced max acceleration, so that the
worst-case blend does not exceed the limits. If a parabolic blend can be
"upgraded" to a tangent / arc blend, then we don't need this
restriction. Previously, this check occured too early in the process of
creating a new segment, which meant some segments ended up with reduced
acceleration unnecessarily.

Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
Mostly for troubleshooting, doesn't affect end-user performance

Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
Instead of just low-pass filtering the measured speed, filter the
spindle speed command sent to the simulated spindle. Now, both the
position and velocity signals will simulate a spindle with inertia.

Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
The spindle-speed-in pin will in many cases be a better estimate of
velocity than the internal estimate we currently use in the TP. Encoder
counters can have much finer time resolution than the servo thread,
leading to smoother velocity estimates.

One benefit is that the "sync_accel" phase actually works now. With a low-count encoder,
the estimated velocity could sometimes be zero if there were no counts
within one servo timestep (sam's test case shows this). Then, sync_accel
ends early, and the position tracker is left with a large error to
correct.

Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
Like the PID component, motion can now estimate spindle velocity if the
spindle-speed-in pin is left unconnected. motion computes a simple
2-point backward difference, which is usable at high speeds and with
high PPR encoders.

Thanks to Peter Wallace for this suggestion (and Jeff Epler for the
original idea in pid.c).

Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
Now, all spindle command settings are collected into one status struct.
Similarly, spindle feedback statuses (position, velocity, etc.) are
collected into a single struct. Note that this change is internal to
motion. HAL pin names and externally-facing status fields should be
unaffected.

Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
Rigid tapping used to estimate spindle position both from the measured
spindle revs, and the commanded direction. This approach is numerically
dangerous, however, because the spindle position itself could be large.
Therefore, flipping the sign on the position would cause an apparent
jump. The previous approach to rigid tapping accounted for this.
However, this new approach should be cleaner and simpler.

Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
…ata.

Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
…osition tracking should be.

Currently, we correct position errors in spindle-sync as aggressively as
possible, given machine acceleration limits. This new HAL pin lets the
user control how aggressive it should be. The valid range is [0.0,1.0],
where 0.0 means no position tracking (pure velocity). 1.0 is equivalent
to 2.x position tracking.

In some cases, reducing the gain will greatly shrink the acceleration jitter, without
appreciably affecting position tracking performance.

Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
This commit adds a new spindle tracking algorithm based on the
trapezoidal motion profile. Particularly for high resolution encoders,
this algorithm should have significantly reduced acceleration jitter.

This also adds a (probably temporary) pin to HAL:

motion.pos-tracking-mode:
0 (default) = new spindle tracking algorithm based on trapezoidal velocity calcs
1 = 2.7.x stock algorithm
2 = 2.7.x algorithm with a correction (here for completeness, but doesn't offer much over the trapezoidal method)

Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
…hed motion.

Feed / speed synch is always disabled after a synced segment (even
if it's then re-enabled for the next one). Unfortunately, this means
that limiting spindle RPM, and then restoring it, has the effect of
inserting two spindle speed commands between each segment of synched
motion. This completely disrupts blending, and affects the acceleration
used during the motion (potentially affecting threading performance).

A safer and easier approach is to pop up a nuisance message to the user
informing them that the spindle speed will be limited, and then just
leave it at the limited speed. Generally, the user will set a new
spindle speed for the next operation anyway.

Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
Signed-off-by: Robert W. Ellenberg <rwe24g@gmail.com>
robEllenberg and others added 8 commits May 1, 2019 18:31
When an arc is 360 degrees, the endpoint and the starting point are
the same.  Naively calculating the XYZ movement using only the
difference between the endpoints overlooks XYZ motion.  When such a
move is combined with a rotary axis movement, the resulting feed rate
will be incorrect.

This patch fixes the problem by passing a parameter to the function
calculating that distance that forces XYZ movement to be recognized.

This may not address the entire issue, since later code in that
function makes further use of the endpoint differences.
Update motion-logger/basic test after changing status buffer fields in
80c92580, "Add spindle-specific fields to emcmotCommand rather than
reusing other fields (with confusing names)."
@samcoinc
Copy link
Collaborator

samcoinc commented May 2, 2019 via email

@samcoinc
Copy link
Collaborator

samcoinc commented May 2, 2019 via email

@samcoinc
Copy link
Collaborator

samcoinc commented May 2, 2019 via email

@robEllenberg
Copy link
Collaborator Author

robEllenberg commented May 2, 2019 via email

@robEllenberg robEllenberg deleted the rellenberg/bugfixes-546-550-167-68-164-for-2.7 branch June 14, 2019 13:17
@robEllenberg robEllenberg restored the rellenberg/bugfixes-546-550-167-68-164-for-2.7 branch June 14, 2019 15:07
@mozmck
Copy link
Collaborator

mozmck commented Jun 9, 2020

@robEllenberg what is the status of these fixes? Have they been merged somewhere? I have a problem on 2.7 with a pause in motion on an ellipse and I'm wondering if a fix for this is somewhere in these fixes.

@robEllenberg
Copy link
Collaborator Author

robEllenberg commented Jun 14, 2020

I opened a pull request for #68 and backported the fix for #704 in another PR for 2.7. I need to pull out the blending fix from this branch and merge it separately because the spindle-sync stuff in the branch is a little much for a point release in 2.7.

@robEllenberg robEllenberg reopened this Jun 14, 2020
@petterreinholdtsen
Copy link
Collaborator

Is there any chance that this huge collection of independent changes can be split up into individual change sets that are easier to review, to increase the chance of these fixes making it into the master branch?

@petterreinholdtsen
Copy link
Collaborator

Rene has volunteered to try to figure out this patch.

@petterreinholdtsen
Copy link
Collaborator

@rene-dev, did you have any luck figuring out this patch?

@petterreinholdtsen
Copy link
Collaborator

Any news here?

@SebKuzminsky
Copy link
Collaborator

SebKuzminsky commented Apr 23, 2023

#550 was fixed in 2.7 by @robEllenberg here: 10c3678

#68 and #546 are both fixed in 2.7.

Only #164 and #167 remain to be examined.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants